How to Set Up Admin Alerts

About Admin Alerts

The Admin Alerts features gives Administrators the ability to get notified as a result of different triggers from SmartHub features such as:

  • Logging notifications
  • Backend failures 

How to Configure Alerts

Alert functionality requires an SMTP server to be configured in the SmartHub Admin site to enable SmartHub to send e-mails to users and administrators.

The alert configuration prompts you for the following:

  • SMTP Server Address and Port – Provided values are the default values for the O365 Exchange email server
  • Credentials to SMTP Server – The credentials are encrypted and stored in the Federator configuration XML file

Admin Alerts

Admin alerts can be configured for the following areas:

  • Delayed answers – will be notified when unanswered questions are logged by the system
  • Elastic service failure – will be notified if the analytics or Q&A Elastic storage

Admins will be able to also configure:

  • Which alerts they receive
  • How often they receive them
    • Daily
    • Weekly
    • Specific days
    • Advanced – Defined with cron expressions
  • Which address the digest e-mail is sent to

Execution Flows

Gathering User Alert Data

  1. SmartHub has a scheduled task that runs every hour
  2. If the alert data is for a subscription with “instant alerts” enabled see flow “Sending instant alerts”

Sending Digest E-mail to Users

  1. SmartHub has a scheduled task that runs every 30 mins
  2. Every time it runs, the scheduled task checks if there’s any digests configured to be delivered at that time or in the next 30 mins
    1. If NO => the task stops
    2. If YES => the task grabs the data to send from disk and sends an email to the user using an HTML template (underscore.js) and them marks the items as “processed”

Sending Instant Alerts

  1. When changes have been detected for a subscription and it has instant alerts enabled the changes will be send to the user using an HTML template
  2. If the subscription also has “Digest” enabled then the items will not be marked as processed so that they can be re-sent during the digest flow, otherwise if only immediate alerts are enabled it will mark items as processed to not be sent again and moved to the archive – see steps d-g from flow “Gathering user alerts data”

How to Administrator Alerts

  • SmartHub features that support admin alerting support 2 types of alerts:
    • Immediate: Immediate alerts will be sent to the admin directly without “batching” since they are considered critical – for example if Elastic is unreachable for more than 5 minutes
    • Scheduled: If a scheduled alert needs to be sent it will be appended to a file on disk and once the scheduled time triggers, SmartHub sends all the alerts to the admin-configured e-mails and the file will be cleared

User Experience

  1. User navigate to the search center
  2. User can see on the left side the list of saved queries along with an indicator if he subscribed to them. The list is ordered so that the user can first see the queries he subscribed to and then the rest of them
  3. User can unsubscribe or change the subscription options from a saved query using the menu for the saved query
  4. User can subscribe to a new query either by using the Query history widget or by using the menu for the search box
  5. Changing the subscription options allow user to unsubscribe, change if and how often he wants to receive digests and if he wants to receive instant alerts
  6. User can subscribe to new results for a query suggestion by clicking the bell
  7. Choose notification frequency (digest option - configurable)

Admin User Experience

  1. Admins have an extra page to configure email settings
  2. Admins configure the SMTP options, the list of admins that receive alerts and the HTML templates used for alerting
  3. Clicking the SMTP configuration will pop up a configuration dialog:

Troubleshooting

User Did Not Receive E-mail with Changes (immediate or digest)

  1. Check the JWT authentication token of the user (localStorage) on http://jwt.io and look at UPN – that’s the email address used to send the alerts – is that the correct address?
  2. If the user knows exactly the document extract the following details:
    1. Last Update time
    2. Created time
    3. Crawl date
  3. Ask the user to check the junk/spam folder
  4. Log-in to the SMTP server and check the sent/outbox folder to see if the email is stuck somehow
  5. Use the details from step 1 to check against the windows history around when the task schedule ran the last time and ensure it ran successfully
  6. Check the logs of the executable to see if it tried to send an email and if there was any issue sending it
  7. Check the alerts file of the user to see if the document is recorded as a “changed document” that he’s supposed to be notified of
  8. Check the logs of the executable to see the query that was send to SH and the response received from SH for that query
  9. Troubleshoot the query to see why it’s not picking up the changes – maybe property mapper is misconfigured or there’s a timezone issue or the backend was down

Admin Did Not Receive a Notification

  1. Check documentation to see if that functionality supports alerting
  2. Check the configured email address in the Admin page for Alerts – is that correct?
  3. Check the spam/junk folder of the admin
  4. Check the outgoing email / sent email folder on configured SMTP server & user – is the email stuck there?
  5. Check the logs to confirm an alert was scheduled to be sent and if the alert was sent – or what error it received
  6. Check the task scheduler to see if the task ran in the past X hours when the notification should not have happened

The UI will allow the customer to configure:

  • How often to check for new documents – default to every 1 hour
  • How often to run the digest checker – default to every 1 hour

Document Checker Application

Console application that will be called every X hours which should iterate through all the alerts and check if new documents exist

The console should process the TOP [BATCHSIZE] alerts that haven’t been checked yet – this way we can configure how many alerts it should try to process and how often it runs.

The searches should run parallel and:

  1. Ensure they only pickup changes from the last time the check happened – this needs to be configurable via the file app.config, such as:

    Copy 
    <appSetting>    
        <appSetting key=”QueryFilter”>CrawlDate>{lastRunTime} OR …. </appSetting>
    </appSetting>
  • This only picks up the newest changed items (ordered by date) and takes the top 3 (configurable via app.config file) since the user doesn’t need to know ALL the items that changed, but rather needs an idea of items that changed to know that there are changed items.

The results of the search are stored on disk in a separate file: HASH(UPN).alertdata.

The results contain the serialized results of all the alerts of the user.

The AlertDataStorage class that is used to write to *.alertdata files rolls over the information.

  1. Write information to the *.alertdata file
  2. Move information from the file to an *.alertdataarchive file
  3. Moved processed information from the *.alertdata file to the archive file
  4. Check if the alertdataarchive file size is greater than a configurable size (10 MB) and clean it up

If the AlertOptions specifies the user wants immediate alerts, then the code composes the email, sends it, and move the data into the archive file.